home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / m68k / 135 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB
  1. Path: python.microcom.com!gator!spellman
  2. From: spellman@microcom.com (Roger Spellman)
  3. Newsgroups: comp.sys.m68k
  4. Subject: Losing Data in HDLC Mode on 68360
  5. Date: 22 Jan 1996 21:03:07 GMT
  6. Organization: Microcom, Inc.
  7. Distribution: world
  8. Message-ID: <4e0u2b$t5j@python.microcom.com>
  9. Reply-To: spellman@microcom.com
  10. NNTP-Posting-Host: gator.microcom.com
  11. Keywords: 68360 QUICC SCC DPLL HDLC NRZI
  12.  
  13. I am having trouble with the 68360 QUICC's SCC in HDLC mode.
  14. Here it the problem.
  15.  
  16. The Company I work for has a product in which a "Controller Card" has
  17. to talk to several "Slave Cards."  To do this, they use an HDLC protocol
  18. over a shared bus at 9600pbs.  Since it is a shared bus, everything is
  19. half-duplex, where the controller sends a request addressed to a
  20. particular slave, and only that slave responds.
  21.  
  22. The sequence is as follows:
  23.  
  24. 1)  Controller turns on Transmitter
  25. 2)  Controller sends HDLC frame addressed to a particular Slave
  26. 3)  Controller turns off Transmitter
  27. 4)  Controller turns on Receiver
  28. 5)  The Slave waits 1.5ms, and sends the HDLC framed reply.  The reply
  29.     may consist of one to four frames.  The first frame is preceeded by
  30.     two HDLC flags, to give the controller a chance to sync up with the
  31.     data.  When done transmitting, the Slave turns off its transmitter.
  32. 6)  When the Controller gets the last frame, it turns off its Receiver,
  33.     turns on the Transmitter, and is ready to begin again.
  34.  
  35.  
  36. The current product uses a Zylogics chip in both the controller and the
  37. slave cards to deframe the HDLC traffic.  The product has been on the
  38. market for several years, without any HDLC problems.  The next Rev of
  39. the HW was modified to use the 68360 QUICC (so that they can add ethernet,
  40. and other stuff).
  41.  
  42. The problem is:  The new controller sometimes fails when reading the first
  43. HDLC frame from the shared bus.  The data stream includes two HDLC flags,
  44. and is running NRZI-Mark, and we are using the DPPL.
  45.  
  46. We believe that the problem has something to do with the 68360 having
  47. difficulty syncing up with the incoming data stream.  This is based on a
  48. change to the 68360 User's Manual.
  49.  
  50. In Rev 1 of the 68360 User's Manual, a new table and a footnote are added
  51. to page 7-138.  (I know that it is new, because of the change bars, and
  52. because it is not in the older Rev's of the manual that we have).  The 
  53. text states "To prevent the DPLL from locking on the wrong edges and
  54. to provide fast synchronization, the DPLL should generally receive a 
  55. preamble prior to the data."  The table lists the desired preambles
  56. (8 bits) for every Decoding Method.  The Footnote states, "The QUICC
  57. receiver require[s] the above preamble".
  58.  
  59. The fact that this footnote is added to this Rev of the manual tells me
  60. that this was a "bug" found late in the 68360 development stage, which
  61. required them to add this to the manual.  Tech Support at Motorola tells
  62. us that this is not true, and that we should be able to run without the
  63. preamble.  As I said, we only fail once in a while (e.g. 2% of the time).
  64. But, that is often enough to cause use problems.
  65.  
  66. Is there something we can do to solve this problem?
  67.  
  68. Let me state what we've tries so far ...
  69.  
  70. One possible solution is to modify the slave cards to send more flags.
  71. We've done this on our new releases of the slave cards, and that works
  72. fine.  The problem is that we have a huge installed base of PROM-based
  73. slave cards, and we cannot upgrade the SW in any of them.  So, we really
  74. need to solve this in the controller.
  75.  
  76. Another approach I tried is to have the QUICC do Internal Timing, rather
  77. than trying to recover the clock from the data stream.  To do this, I set
  78. RDCR to 00, which sets the DPLL clock rate to 1x clock mode.  I thought
  79. that this would essentially "turn off" the DPLL, and hence get rid of
  80. the preamble requirement.  This seemed to improve the situation a little,
  81. in that we stopped losing the start of frames.  But, we began seeing a new
  82. problem:  we got DPLL errors on the last frame of some multi-frame sequences.
  83. (I guess that I really did not turn off the DPLL -- Is there a way to turn
  84. it off?).  One could possibly blame this on the different clock speeds on
  85. the Controller and Slave.  But, since the total number of bytes sent is
  86. less than 200 bytes, and since we are running (crawling) at 9600 bps,
  87. I find that hard to believe.
  88.  
  89. I'd really appreciate hearing from anyone with any suggestionos or
  90. solutions.
  91.  
  92. Thanks a lot.
  93.  
  94.  
  95.  
  96.  
  97.